A particular attribute value for a data attribute may only be applicable (i.e. true) in a certain situation. Applications that share use of the attribute need to know about the situation when the attribute value is true in order to make proper use of the attribute. For example, the value of a telephone number attribute “telephoneNumber” for a person may only be applicable during a particular time of day or may represent a home, business, mobile, facsimile or other telephone number.
Data attributes are often shared among multiple applications, such as in business applications for conducting electronic commerce (e-commerce, whereby transactions for a variety of goods and services are conducted electronically) or electronic business (e-business, whereby business processes—e.g., shipping, procurement, staffing, etc.—are transformed so as to be conducted electronically). A situation under which an attribute value is applicable may be specific to a particular application. Consider an attribute “preferredDessert” representing a person's preferred dessert of “ice cream”. For an application that manages data about dessert preferences in various restaurants, it may be desirable for that application to associate a restaurant with the preferredDessert attribute value “ice cream” to indicate that the person likes that dessert in the particular restaurant. A further application may track dessert preferences under different seasons and associate the preferredDessert attribute value “ice cream” with the season “summer”. Consider further a purchasing application that may gather cost or quantity information from a variety of supplier sources. Pricing information may be represented in a supplier's preferred currency (erg. $, , and ¥) or quantity of a particular supply in a variety of units of measure (e.g. ton and tonne, lb and kg). A sales or an inventory application may wish to represent the same attributes in different currency or measure units.
A typical solution to relate an attribute value such as “ice cream” with further information such as the preferred season for eating ice cream or the preferred restaurant for purchasing ice cream is to create an attribute for each of the different situations or contexts. That is, a typical solution is to create the attributes “preferredDessert_Spring”, “preferredDessert_Summer”, etc. to represent the seasonal dessert preferences.
A drawback associated with using different attributes for the different contexts is that such contexts must typically be anticipated in advance and must remain constant. In the example above, the seasons are known and are constant. But often, contexts change or are not known in advance and as such using different pre-defined attributes is not ideal or even feasible. If dessert preferences need to be tracked according to restaurant name, for example, the names may not be known in advance and may change. Using multiple different attributes may also be cumbersome when there are many contexts.
In a data sharing environment where data are shared among many applications, some contexts are only meaningful to a single application. A proliferation of attributes for a context having narrow usage is wasteful of resources.
A solution to some or all of these shortcomings is therefore desired.